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A Word from the Secretary 

The operative word this term must be "DATABUS". We are the first 
committee to get this magazine out for over four years. Who cares if this 
term's meetings have been few and far between — we have brought out 
this heavyweight tome (well it is much heavier than the usual 
newsletter). 

We have come up with a good mix of humour, serious reviews, 
software techniques and even more humour. There is a competition, 
and a number crossword. 


My thanks to the outgoing committee (1988/89): 


Treasurer 
Databus Editor 
Resources 
Publicity 


Gavin J Stark 
Paul M Theobald 
Martin W Baxter 
Gregory Emmett 


Christ's 

Churchill 

Pembroke 

Trinity 


I hope the incoming (1989/90) committee can do even better than this 
year: 


Secretary 
Treasurer 
Databus Editor 
Resources 
Publicity 


Paul M Theobald 
Paul Martin 

C Christopher Anderton 
Martin W Baxter 
Philip Elwell 


Churchill 

Magdalene 

Downing 

Pembroke 

Emmanuel 


I wish you all the best for the coming year. My thanks to CUSU for the 
loan of facilities, and all those who helped us to prepare this magazine. 

Paul Martin 
Secretary 
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HISTORY OF CUCS 

By your historical correspondent Paul Theobald 

Cambridge University Computer Society is a relatively new society, 
started twelve and a half years ago in 1976. However significant 
changes in computer technology have seen radical changes in club 
interests, and many of the activities in which former members were 
involved seem quite antiquated and some of the tortuous methods 
through which the members put themselves through to build a piece of 
hardware or software, where nowadays we would just buy it off the 
shelf for a few pounds, seem quite funny now. But don't laugh too much, 
no doubt in another ten years time Computer Society members will be 
laughing at the things we're doing now! 

I have found much of the information in this article from looking back 
through past issues of the Databus magazine. Yes, they used to be quite 
frequent in those times, published every term. The earliest issues of 
Databus can be found in no less than the Rare Books section of the 
University Library along with all the old ancient Egyptian scrolls. It just 
shows how highly valued they are by the University. Later editions are 
in the Periodicals section of the UL, and the most recent can be found on 
Phoenix in the directories CUCS.DATABUS. See the UL computer 
catalogue under Databus, CUPG & CS, Cam.b.21.71. 

The society was founded as the CU Processor Group in 1976 and they 
dealt mainly in hardware. The first issue of Databus was in Lent 1977. It 
consisted of eight single-sided, photocopied, typed A4 sheets, (which 
will probably be how this one will end up unless I get a move on) and 
cost 15p. The editorial read "The CU Processor Group was set up to 
stimulate and promote the activities of people interested in the 
hardware and software aspects of modern computing." In those days 
computers were hard to come by, so the group used to have great fun 
building their own. Their first effort was to build the LSI-11 computer, 
which was apparently a PDP-11 on a single board. Initially it consisted 
of a 6800 processor with 256 bytes of memory. Those were the days 
trying to squeeze every last byte out of a computer, real programming — 
stops to wipe a tear from his eye as he remembers his old IK ZX81. But 
obviously even for such a talented group as the CUPG trying to write 
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decent programs in just 256 bytes of hand assembled 6800 machine code 
was impossible, so the club saved up to buy an extra 16K expansion 
which cost the staggering amount of £300. They then proceeded to write 
an operating system for it, followed by an assembler and an editor. 
Further items featured were an output device for a computer, getting a 
complete ASCII character set out of 7 segment LEDs. The alphabet ends 
with the sequence: 

l_l I IJ Z\ 

U _ _ll_ 

\ 

The second issue of databus was for Easter 1977. It had grown to 12 
sides of A4, and the price had soared to 20p. The major article featured 
was a build it yourself modem, which was to be used not to hack into 
mainframes over the telephone network, but quite innocently as a tape 
interface so that all those wonderful programs that had been written 
could be saved to a standard tape recorder to save an awful lot of 
typing every time, if punching numbers into a hex-keypad can be 
considered typing! Apparently the device worked quite well, but if an 
error occurred it was recommended to clean the tape with 
Propan-2-ol, imagine having to do that nowadays! Also at that time a 
6502 system called "Paddy" was being built for about £50. It had a 256 
byte operating system and a cassette loader for it of just 16 bytes, now 
that's real programming! The club then had 22 members and each one 
was listed in the magazine, a great way to fill out the pages. 

By the third issue the club had got its own filespace on the IBM 370. 
Projects in this issued included a home-made paper tape reader and 
asynchronous dual processors. There was also an article on how to 
bootstrap a machine, so useful in those days of kick start models! 
Membership then cost £3 per year or £6 for life. It's not much more 
today, what a bargain. 

1978 saw the club mature a little, with the first stand at the societies' 
fair, and with talks from professionals from Plessey, Comart, and RCA. 

Later that year a member of the club had a go at building his own 
microprocessor (micro?) out of discrete components. It was a 6-bit 
processor able to do the standard mathematical operations of +/ -, x, +. 
It had a telephone dial for input, but apparently suffered from a FIDO 
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(Frighteningly Inaccurate Data Operator!) It also featured a 16-bit TTL 
based minicomputer with a 5 amp processor! It was capable of 
multiprocessing and virtual storage. The first programming 
competition was held to produce a 2 byte random number generator. 
The rules included: must be relocatable; re-entrant; no self-modifying 
code; must not violate CS rules; and must not jeopardise system 
security. Obviously even in those days there must have been an awful 
lot of hacking and naughtiness going on from students! 

December 1978 mentioned that the club had had a great increase in 
membership put down mainly to the offering of free beer at the 
societies' fair (now that's a good idea). The programming competitions 
this time were more involved: an arbitrary precision decimal multiply 
(or if insane divide), bubble sort of arbitrarily sized array of binary 
numbers, a BCPL 'SWITCHON' implementation and a CAR, CDR, CONS 
for a LISP system. The magazine had now increased again in price to £1 
for non-members for a year (3 issues?), but was free to members. 

September 1979 mentions a punt joust against the rival Computing 
Society which had recently been formed. The best answers to the last 
competition were given: the multiply had been written in 65 bytes taking 
127ir jxs for n bit numbers. Not bad even by today's standards. As usual 
no-one appeared to have tried the BCPL or LISP questions. The group 
went on a spending spree to buy a real computer instead of building one 
of their own, and came back with ... an Acorn Atom. (Things really 
haven't improved much since then.) 

Moving on to the periodicals section, October 1981, issue number 9. The 
group had bought their own "computelet", a ZX80, and had managed to 
secure a 10% discount from Acorn (which we have just regained this 
year - in fact we got 20%). I like the opening article from the secretary — 
"... here are a few comforting words from the sec: a soft pillow, central 
heating, waffles, 68000, a pint of Theakston's, 10Mb of on-line storage, 
long holidays, plastic mac, (oops! what a give away) ...". Databus 
contained many articles for the computer of the moment the ZX81, and 
there were still articles for the 6809, "the best processor in the world". 

Issue number 11, in October 1984 was for the joint CU Processor Group 
and Computer Society. It was now down to A5 size and printed 
properly on a computer. It contains an article from the then secretary 
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Adrian Dickens on how he wrote the Advanced User Guide, with all the 
fun of melting discs, sitting for hours behind an empty stand at the 
Acorn User show, more of which he told us about at his talk to us last 
term. The article was titled "How to make a million pence in two 
months" (that's £10,000 so I think I'm giving up writing for this 
magazine. I'm off to write a book, how about the Advanced User Guide 
to the ZX81, better late than never!) 

The last issue, number 12 in March 1985 was heavily into software, 
hacking and Beebs. Lots of people doing nasty things to their micros to 
get them to run just that picosecond faster, poking directly into CRTCs 
and over the tube. The BBC micro had taken over the Computer Society, 
with most of the articles and demo programs for it. Much the same way 
as it is today in spite of the final article claiming it to be "an ageing 
relic", though now I suppose it's even more of an ageing relic, almost an 
antique in computing terms. I wonder if it will survive until the next 
issue of Databus. Only time will tell... 
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Modula-2 — A User's Comments 

By Chris Anderton 

The programming language Modula-2 has been designed by Nicholas 
Wirth as a successor to Pascal (named after the French mathematician). 
Modula-2 is the result of the structured top-down design of Pascal 
combined with influences from Modula and Mesa (the Xerox 'it has it 
all language'). Modula-2 attempts to take the most useful and primitive 
functions of Mesa and combine them to form a structured programming 
language that can be used for a wide range of programming 
applications. 

The Module 

The biggest shock when learning Modula-2 is the concept of the module 
as a compilation unit. There are three kinds of compilation unit: 

• [program] MODULE 

• DEFINITION MODULE 

• IMPLEMENTATION MODULE 

The program MODULE 

The ordinary module (program) is what the average Pascal hack would 
expect to find. A name, some definitions, some procedures and functions 
and some code following a BEGIN statement. It also ends the same, with 
a full stop. 

When it is coded the user only writes MODULE, however it is called the 
program module and why PROGRAM MODULE is not written I do not 
know. (Modula-2 does not believe being brief normally and all other 
modules are named.) The structure is similar to that of the Pascal 
'program' with a naming, CONSTants, TYPES, VARiables and then 
PROCEDURES and PROCEDURE functions (in Modula-2 a function is a 
procedure that returns a value). 
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The main immediately obvious difference is in the first few lines of code. 
These normally contain FROM MODULE IMPORT requests. This means 
that another type of program unit is at work — the MODULE. 

The DEFINITION MODULE 

These are normally very small code fragments, of less than a couple of 
screenfuls. They exist to define interfaces. The idea is that these modules 
supply information to the programmer and program module about 
what procedures types and constants are available in a given library 
without supplying implementation details. This abstraction permits 
reprogramming of implementations without having to change clients as 
the interface will not have changed. 

In older versions of the language you will see the phrase 'EXPORT 
QUALIFIED' which says what is made available to the client, but more 
recently this has been dropped in favour of a total export policy. 

The IMPLEMENTATION MODULE 

These are are the things that really make Modula-2 different from 
Pascal. Here you define library procedures that can be used by many 
different programs. You must specify the values of any undefined 
constants and types left from the definition and you must code up your 
functions and procedures. I will leave the subject of Modula-2 coding 
till later. 

The best bit about IMPLEMENTATION MODULES (apart from the work 
saving) is that they have initialisation blocks at the bottom. This is to let 
you initialise global data amongst other things. 

The Language 

The language used in Modula-2 is remarkably similar to Pascal. The 
main difference is that it is case sensitive, ie the variable 'Hello' is 
different to the variable 'hello'. Most system (but not library) functions 
and language features are in upper case. The other main differences are 
that for every END there is not a BEGIN and that there are no labels or, 
hence, gotos. 
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The way that most commands work is that they assume a block of 0 or 
more commands (unlike Pascal's 1 or more) and so an END is always 
necessary making a BEGIN superfluous. 

An advantage that this brings is that the behaviour of IF ... THEN IF ... 
THEN ... ELSE ... is now defined as the ELSE belonging to the innermost IF. 

The naming convention for variables is simple. You put a capital letter 
where you expect to see a space in English. Hence the procedure called 
write string is coded as WriteString. This also makes code very 
readable. 

I have two main quibbles with the language. The first is that the CASE 
statement looks unlike all other statements available as the different 
CASES are separated with a 'I' and not terminated with an END. My 
other is that there is a function ODD. This returns a boolean depending 
on whether a variable is odd or not. I find that this is useless and placing 
it in a supposedly minimalist main language self contradictory. 

The Standard Libraries 

I have used two Modula-2 systems. Modula/370 and Modula-2 under 
Ultrix 1.2. Of these Modula/370 is by far the more standard. The library 
modules supplied are supposedly standard but as there is no defined 
standard compilers can (and frequently do) get away with what the 
writers want to do. All I can say is that the following should be supplied: 

• InOut 

• Storage 

• MathLibO 

• Streams 

• Terminal 

• SYSTEM 

• LineDrawing 

All that can be said without going into great detail is that they are all 
available in some way, possibly with different names (like TermlO for 
Terminal or MathLib for MathLibO) except for LineDrawing which 
despite being 'standard' according to Wirth is rarely implemented. 
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Hence I can conclude by saying that Modula-2 is an improvement on 
Pascal but there is still some way to go as the language lacks some 
features that would make programming in it easier. I would like to see 
the addition of an INITIALISE block to modules to allow for the 
initialisation of data in one go. The use of unintialised data could then 
be easily flagged. Also I would like to see a defined standard for InOut 
and arithmetic. (Is an INTEGER 16 or 64 bits? Do 32 bit machines have to 
provide LONGINT? Why no LONG or DOUBLE REAL type? ) Further a 
packed ARRAY would be good also. (Who need their BOOLEANs aligned 
on a full (32 bit) word boundary on 370 or VAX machines?) Finally why 
limit SETs to 32 members? There is no reason for this — except for 
compiler writer laziness. 

So Modula-2 is a useful, clean, powerful language, but it could be 
improved. 
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Preliminary details on the new 
language DALI 1.0 

By shane murphy with additions from Elias Papavassilopoulos 

Although Pascal is a very popular language for computer programming, 
it has frequently been criticised for its fussy syntax and emphasis on 
clear and logical structure; many people have claimed that this makes it 
intuitively difficult to use. DAU, on the other hand, suffers from no such 
problems. It is designed to work in exactly the way that the human mind 
works — thus greatly reducing coding time. The full specification of 
DALI 1.0 will be available shortly, but in the mean time here are some 
extracts from the preliminary copy of the system user guide. 

Variable Types 

All existing Pascal types are supported. Additional types include: 

string A variable of unknown length; attempts to discern the 

length of a piece of a string also return errors. Not to be 
confused with the BASIC type of the same name. 

surreal An extension to reals, which allows the processing of 

variables or constants of different types. For example, 

p := 6 + "melted clock"; writeln(p); 

could produce any output from '42' to 'banana', 
complex Similar to FORTRAN, but with a slightly different syntax: 

z := 3 + 2j; write(z*l-j); 

mindboggling This type has not yet been fully defined, but its 
preliminary definition is: 

"A seventeen-dimensional array of complex numbers, 
which point to secondary arrays, containing strings, and 
also pointers to the first array." 
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boydiean 

zen 

disarray 


stack 

mess 

pile 

desk 


A sub-class of boolean, extended to include true => false, 
true + true => false, and false * false => true. 

Another sub-class of boolean; expressions of type zen do 
not return values, but indicate in some subtle way that 
they have understood your intentions. 

Unlike an array, which has fixed subranges, the disarray 
data type is defined with respect to variables. As the 
values of these variables change during the program, so 
too does the size of the disarray, and any memory freed 
is immediately reclaimed. If the disarray grows larger 
than its initial value, other variable storage, or even the 
program code itself, may be overwritten. 

A purpose-defined stack type, to supplement arrays. 

Like a stack, but the elements are 'pulled' in a random 
order from the top, bottom, or middle of the stack. 

Also similar to a stack, except that the element you want 
is always at the bottom where it cannot be 'pulled'. 

A random array of messes and piles. 


Assignment Operators 


The traditional := (becomes) is retained, but several new assignment 
operators are available in addition: 

m= (might be equal to) — allows non-definite arithmetic; 

that is, arithmetic using numbers whose values are 
uncertain. For example: 

x := 2; x m= 3; 

is the DALI equivalent of the phrase "x is 2... but then 
again, it might be 3". Instead of forcing the user to decide 
on which value x should take, both values are specified. 
The DALI language will choose whichever it feels is the 
more appropriate, at run-time. 
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- = (is not equal to) — this must not be confused with the 

logical operator NOT. An example of the use of ~= is: 

ps ~= 4/ writeln (ps); ps := ps + 1; writeln (ps); 

The first writeln may print any value except for the 
integer 4. The second will print any value except for the 
integer 5. 

Logical Operators 

and, or, not, exor ( exclusive or ) are implemented as 
usual. Added operators are exnot and exand. 

Program Flow 

if... then... else... except 

The conventional if ... then ... else has been extended by 
the except command, which provides a further twist to 
the logic, except is always executed after the if ... then ... 
else expression has been evaluated, which means that 
the program may find it necessary to undo the effects of a 
previous operation, except statements may be embedded 
to an arbitrary depth, or placed in recursive procedure 
calls to make the interpreter really sweat. 

Additional equality operators allow for programmers re¬ 
assigning variables in error or forgetting to assign 
variables in the first place. 

if x was= 5 then goneto missedit 
if x willbe= 7 then goingto getready 

In a more extreme case some compilers also allow the 
shouldhavebeen= relation: 

if x shouldhavebeen= 5 then wouldhavegoneto label 

comefrom This statement, is roughly the opposite of the goto, in 
that it is placed at the point in the code to which, rather 
than from which, jumps should be made. For example: 
label test; 

if (a=l) then ... {rest of program} comefrom test; 
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gobackwards 

gosideways 


for... do 

while... do 


The implementation of the comefrom statement requires 
that the language be either compiled or pre-interpreted, 
so that the necessary comefrom stack can be built. 
Alternatively some interpreters are designed to perform 
random jumps from place to place in the code, until they 
can encounter and execute a comefrom statement. 

A useful extension to comefrom is the don'tcomefrom 
command as in: 

if x = 7 then don'tcomefrom test; 

Reverses the flow of control. 

Moves the flow of control into an alternate quantum 
reality. In the Many-Worlds Interpretation a significant 
degree of parallelism can be achieved on a single-chip 
machine by running the program in several quantum 
universes simultaneously. See "Quantum Theory, the 
Church-Turing Thesis and the Universal Quantum 
Computer", by David Deutsch, 1985. 

Now accepts the standard looping constants several, 
enough and plenty as in: 

for i := 1, several do 

This has now been extended to include statements of the 
form: 

while (condition) don't {program block} 

The additional unless ... clause allows extra conditions to 
be added as an afterthought. For example... 

a := 100 

while (a>-100) do 
begin 
b = 1/a; 
a := a-1; 
end; 

unless (a=0); 


16 



DATABUS March 1989 


If the unless condition is found to apply, it will attempt to cover up its 
mistake. One early optimising system even went so far as to crash the 
hard disc and electrocute the operator in an effort to conceal the error. 

Functions 


calculated) 

guess(x) 

update(x) 

rand(x) 


calculates x from a formula in the global workspace, 
as above but much faster since it ignores the formula, 
randomly adjusts x. 

returns a random number between 33 and 36. 


noise(x) adds noise to the three most significant bits of x . 

crash(x) bombs out the program, overwrites the run-time system, 
deletes the values of all intermediate values and 
performs any low-level operations which might 
conceivably cause hardware damage to the host 
machine. 


An extended implementation is planned for DALI 2.0, which may include 
the inspiredguessO function. 

Temporally Global Variables 

Example: 

var temporal real a,b; 

The temporally-global variable is one of DALl's most powerful features, 
since it allows tedious number-crunching to be performed at the end of 
the program, where a little extra delay is not critical. For example, 
consider the following program fragments: 

var temporal real s; 

• • • 

writeln(s); 

for a=l to 1000 do s=s+l/a 

The program makes use of the temporally-global variable s to print the 
result before calculating it, thus allowing the tedious calculation to be 
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done after printing the result, whilst the user is busy reading the output, 
going to a supervision, drinking coffee, etc. 

DALI 1.1 - The Upgrades Continue 

Version 1.1 of DALI has now been released. The only improvement is the 
addition of a new command, WU. Wu has no parameters, and returns 
no values. It simply prints the message "Wake Up!". It is provided in 
order to improve the language's performance in Dr. Frank King's 
Compactness-of-source-code benchmark. 

NOTE: WU requires at least 512K of available memory on the heap in 
order to function correctly. 

Conclusion 

DALI is an extraordinarily powerful language capable of executing not 
just in real time but in imaginary time into the bargain. An optional 
module is available to exploit the hidden dimensions of spacetime as 
and when they become incorporated into physics theories. Twistors, 
axions, Goldstone bosons, etc, are all catered for as language 
primitives. It is the ideal language for the future. 
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Independent ECONET 
Communication 

by Martin W Baxter, Pembroke 

The Econet system links a number, usually about 10-50, of BBC or 
equivalent machines. Each has an autonomous Econet ROM which 
interfaces with the network. There is no, in any important respect, one 
machine controlling the network or "in charge", though many systems 
give that impression. Traditionally one machine, perhaps with hard 
disc, is set aside as a file-server which will process filing system 
commands in a similar way to the DFS. We are going to confine 
ourselves to a lower, but more flexible, level of communication. 

Although Econet has other facilities, we are going to consider the 
send/receive primitives. These behave much like a telephone call in that 
you "dial a computer's number" and, if it is not engaged and answers 
the bell, you can give it a message (a block of bytes). 

One facility not open to BT users is the ability to choose the "line" that 
you wish to use. On Econet there are a number of ports (255 in all) which 
you can choose to communicate on. These have no physical meaning, 
only a software significance, but a machine receiving on a particular 
port will not get a message from another machine transmitting on a 
different port. 

The listings at the end set up and operate the send and receive control 
blocks which direct operations. Each BASIC procedure has 4 arguments: 

(1) SN% the station number, that is the Econet number of the 

machine you are sending to or receiving from. Usually 
networks have this as less than 256 though it is a 2 byte 
number. Numbers &FFFF and &00FF are reserved for 
broadcasts, and &0000 is described below. 

(2) PO% the port number, as described above. This must be 1 byte. 

Ports &90-&9F, &D0 and &D1 are reserved for file-server 
communications. 
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(3) SA% the start address of the data to send if transmitting, or 

start of buffer which will have data read in if receiving. 

(4) EA% the end address of transmission data block, or the 

maximum address of received data (this need not be 
achieved). 

Example: 

Machine #5 sends its (Mode 7) screen to a storage address (&6000) in 
machine #29 on port &50 by, 

#5: PROCTX(29,&50,&7C00,&8000) 

#29: PROCRX(5, &50,&6000,&6400) 

For receiving it is possible to set either the station number to &0000, 
enabling receipt of messages from any machine on the port, or to set the 
port number to &00, enabling receipt of messages from the other 
machine on any port. If both machine and port are set to zero, the 
routine will pick up all messages for its own machine and any messages 
broadcast on the network. 

When the receive routine (PROCRX) is called, it attempts to open a 
control block (OSWORD &ll). The control block number (CBN%) is 
returned in the result byte - the first byte of the block — and is 0 if the 
attempt failed. The block is polled (OSBYTE &33) until something is 
received, when bit 7 of X is set. If nothing is received the machine will 
hang, and on escape or other exit it is wise to delete the receive block 
(below). On reception the block is read (again with OSWORD &11), 
deleting the block (though not the data). The data is now in the machine 
at the start address (SA%). The actual end address, as opposed to the 
greatest permitted (EA%) is stored in CB%!9. 

There is only space for 16 receive control blocks so if too many build up 
due to non-reception or otherwise problems will occur. Half-used blocks 
can be deleted using OSBYTE &34 with X on entry holding the control 
block number. (Fully used blocks are automatically deleted by reading 
them.) 

A%=&34:FOR X%=0 TO 255:CALL &FFF4:NEXT X% 
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could be a good line at the start of programs or in error-handling 
routines. 

The transmission procedure (PROCTX) calls transmit (OSWORD &10) and 
then polls the transmit block (OSBYTE &32) for an error report returned 
in X. Bit 7 is cleared on transmission and bit 6 is set if an error occurred, 
with the error code in bits 0-4. The 5 errors (lines 200-240) are: 

(i) Line jammed — indicates short circuit on network or similar — see 

network controller. 

(ii) Net error — probably temporary Econet noise. 

(iii) Not listening — other machine not ready at that instant (check 

plugged in and running PROCRX). 

(iv) No clock — Econet needs an external clock plugged in. 

(v) Bad TX control block — software fault. 

Errors (ii) and (iii) are not serious and if they occur the program will try 
again with half a second delay between trials for 10 (=TY%) tries in 
total. This is advisable as in some applications there may well be a little 
wait for a remote machine to start listening. The other errors crash the 
procedure in a very messy way, but there's little else to be done and they 
ought to be very rare. 

10 DEFPROCTX(SN%,P0%,SA%,EA%) 

20 LOCAL CB%,TY%,DE%,TR%,A%,X%, Y%,NF%,ER% 

30 DIM CB% &10 

40 CB%?1=P0%:CB%!2=SN%:CB%!4=SA%:CB%!8=EA% 

50 TY%=10:DE%=50:REM 10 tries with 0.50 secs between them 
60 REPEAT 

70 X%=CB% MOD &100:Y%=CB% DIV &100 
80 A%=&10 
90 REPEAT 

100 ?CB%=& 8 0:CALL &FFF1 
110 UNTIL ?CB%<>0 
120 REPEAT 

130 A%=&32:TR%=((USR &FFF4)AND&FF00)DIV&100 
140 UNTIL (TR% AND &80)=0 
150 ER%=(TR% AND &1F) 

160 NF%=(ER%=1)OR(ER%=2) 

170 IF NF% THEN TIME=0:REPEAT:UNTILTIME>=DE%:TY%=TY%-1 
180 UNTIL TY%=0 OR NOTNF% 
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190 IF TR%=0 ENDPROC 

200 ON ER%+1 GOTO 210,220,230,240,250 

210 PRINT"Line jammed":END 

220 PRINT"Net error":END 

230 PRINT"Not listening":END 

240 PRINT"No clock":END 

250 PRINT"Bad TX control block":END 


10 DEFPROCRX(SN%,PO%,SA%,EA%) 

20 LOCAL CB%,CBN%,A%,X%,Y% 

30 DIM CB% &10 

40 !CB%=&7F00:CB%?2=PO%:CB%!3=SN%:CB%!5=SA%:CB%!9=EA% 

50 X%=CB% MOD &100:Y%=CB% DIV &100 
60 A%=&11:CALL &FFF1:CBN%=?CB% 

70 A%=& 3 3:X%=CBN% 

80 REPEAT UNTIL ((USR &FFF4)AND&8000)<>0 
90 X%=CB% MOD &100:Y%=CB% DIV &100 
100 A%=&11:?CB%=CBN%:CALL &FFF1 
110 REM length = CB%!9-CB%!5 
120 ENDPROC 

Econet in Cambridge 

The University Computer Service's Mond Console Room has its 
machines on Econet, even though there is currently no file-server. The 
system clock is by the machine nearest the printer door but it is not 
always plugged in. Be warned that not all the machines will work 
satisfactorily (or indeed at all). Remember also that Mond is a work 
area and Econet users (because of the need to use more than one 
machine) must be careful not to disturb others. 

The Department of Applied Mathematics and Theoretical Physics 
supports the CATAM (Computer Aided Teaching of Mathematics) Room 
which has a number of Econeted BBCs and BBC+s and a Level 2 file 
server. This is open to all Mathematics students. 

References 
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Connectionism: AI Solved 

By Tony Robinson 

For anyone working in Artificial Intelligence, Psychology, 
Neurophysiology or Cognitive Science, the new and trendy field is 
Connectionism. Connectionism proposes a radically different method 
of computation from traditional methods, it is holistic, self organising, 
fault tolerant, robust, distributed and parallel. Current methods of 
computation are none of these. 

Connectionist models are learning machines, they are presented with 
examples of an input and the desired output and the machine adjusts a 
large number of internal parameters so as to be able to compute the 
output when given only the input. Connectionist models are also very 
simple, typically they consist of a set of units and a set of links between 
units. Each link has a value, known as its weight, and each unit has a 
value, known as its activation. The activation of a unit is a simple 
function of the activation of all the other units it is connected to, 
multiplied by the weight of the connection between the units. 

Connectionist models are not new, they were around at the birth of 
computer science? However, early models were limited in their learning 
ability 2 and they rapidly lost popularity. Recently these learning 
difficulties have been overcome^ and hence the resurgence of interest. 
So now that we have a general machine that can learn to perform a 
mapping by presentation of examples, as in figure 1, what can we do 
with it? 


+-+ 

-\ | static |-\ 

input > I output > 

-/ | ne t j-/ 

+-+ 

Figure 1 

Firstly note that we only have a machine that maps a static input 
pattern onto a static output pattern, ie. the machine has no internal 
memory. This restriction may be overcome by partitioning the input into 
two types, external input from the outside world, and internal state 
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input. Similarly the output is divided into external output to the world, 
and internal state output. The state outputs are linked to the state 
inputs, generating internal memory, and upgrading our machine to the 
class of finite state automata? This type of machine is known as a 
dynamic net and is computationally a much more powerful device. A 
dynamic net can learn to map any input stream onto any output stream, 
as illustrated in figure 2. 
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Figure 2 

One further step is possible. Instead of learning by explicitly presenting 
the answer to the machine, it is possible to tell the machine whether it 
has made right or wrong decisions in the past with a training signal, 
known as the utility signal. 5 To do this all we need is another dynamic 
net to learn the relationship between the past inputs and outputs and 
the utility signal, and then use the knowledge of this relationship to 
maximise the utility signal, ie. get the problem right more often than 
wrong. In fact the two dynamic nets can be combined into one, as in 
figure 3. 

And this is where the theory stops. So far very few of these utility driven 
dynamic nets have been built (in the jargon they are "a current research 
interest")/ but their computational potential is enormous. Suppose a 
large chemical plant had to be controlled knowing only the values of the 
input and output variables and the current performance. Given time 
this net could form an internal model of the plant including what factors 
affect performance, and then adjust the input to the plant so as to 
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maximise performance, without ever being explicitly told the internal 
details of the plant. 
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A more interesting application is to the field of Artificial Intelligence. As 
a thought experiment, imagine a net with touch, audio and visual inputs 
and with motor and audio outputs. Now wire the utility signal up so 
that it represents the state of repair of the machine, eg. high when the 
batteries are charged or low when it has a flat tyre. Now after a bit of 
experimenting the machine can learn simple facts that excessive 
movement causes a low utility signal because the battery becomes flat. 
Also as a result of moving around the machine can model the 
relationship between the motor control outputs and the change in the 
vision inputs. The machine can even become aware of itself, in that it 
can learn that changes in the external world are a direct result of its 
own actions. If there were more than one of these machines then they 
could learn to communicate using the audio channel in order to 
mutually increase the utility signals of the communicating machines. In 
effect one machine could solve a problem by asking another machine. 
Now consider a shortcut in this process whereby the machine asks itself 
questions, at first using the same communications protocol as 
inter-machine communication, but later in a silent inner voice? 
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So who is to deny these machines consciousness? 
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ABSTRACT - Recent Trends in 
RD-work in London. 


A prescient paper in a recent edition of Elektronik Brane foretold on a 
nightmarish world of mass unemployment, society being the victim of 
increasingly powerful and sophisticated computing resources. However 
some R & D is now being invested in Retro-Development (RD). Read 
on... 

Earlier this year a colleague of mine wrote of the urgent need for the 
"Retro-Development" of computing resources to help us to cope with 
the future by redeploying the past 1 . There are many threads to RD. My 
learned colleague (actually just a mate of mine) concentrated on 
software RD. But software can only be as bad as the hardware that 
won't run it! I shall thus attempt to fill out the picture by informing the 
reader of the latest hardware RD. 

There are three distinct strands of hardware RD. 

Firstly, we may simply replace new machinery with old machinery, this 
is a superficially attractive scheme but flawed as too many of the old 
systems actually worked quite well. 

Secondly, there is unplanned RD. As I put pen to paper (my computer is 
currently 'down') countless manufacturers are producing new 
hardware which is significantly less usable and useful than the 
equipment it is intended to replace. Such RD there will always be but it 
is outside the scope of this paper. Readers interested in further study of 
this area should acquaint themselves with GEC's product line. 

Thirdly, and the subject of the rest of this paper, is planned RD. It is this 
work which will produce the spectacular hardware flops that a sane 
future demands. Project TINA (There Is No Acronym) is attacking 
hardware design on a number of fronts. Some of the lines being 
followed are now described. 
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Central to RD is the Basey machine. It is well known that a number 
system with radix e offers the greatest representational efficiency for 
the two numbers 0 and 2.something. At the moment we have the worst 
of all worlds: binary representation is neither comprehensible to 
humans nor efficient for machine storage. The Basey machine will 
clearly be a significant advance. Current work includes trying to 
calculate e to 2 sig. figs., analysis of how to overcome a few minor 
electrical engineering problems and strenuous efforts to increase the 
level of funding of the project. 

Equally vital to RD is work being undertaken on computer memories. 
We have long suffered the misnomer "random" as in "random access 
memory". As any fool knows, memories are anything but random but 
closely resemble a New York street plan. CRAM (completely random 
access memory) will put this matter right. Machine bit and byte orders 
(thank you DEC for pioneering work here) will vary randomly and 
frequently. Information retrieval will be simple but the information 
retrieved will be unpredictable. Current work in hand includes the 
purchase of a copy of Knuth's seminal tome to discover if an algorithm 
exists which might allow the retrieval of particular items of 
information. 

If CRAM fails to slow down even the supercomputers of tomorrow, 
information hiding will come to the rescue. Information hiding, as an 
aid to program design, is well known. Hardware information hiding is 
less subtle. If it should happen that some information is actually resident 
in primary memory, the hardware will quickly page the memory out to 
disk and then archive it to tape. The tape heads will then be realigned 
and... 

Whatever happened to bio-memories you may well be asking? TINA has 
found a dramatic use for them by considering architectures for the 
future. In an attempt to both go forward, and yet at the same time 
backwards, form parallel architectures we have decided to develop 
cereal architectures. When funding allows a variety of cereals will be 
bought for benchmarking. 

Project TINA shares the current optimism for optical memories, optical 
in the sense of the memory being easily visible to the human eye. Many 
output devices will become redundant if the memory is directly visible. 


si 
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The long term goal of making memories truly human readable is some 
way off. In the short term binary spectacles are being developed which 
will allow the wearer to read stored information conveniently. 

The aforementioned optical memories will inevitably lead to machines 
being somewhat larger than they are at present. We will leave the age 
of the mini and the micro and enter the age of the Macro. This should 
not be viewed as a Luddite move turning the clock back. The executive 
will still be able to have a computer sitting on his/her desk, although the 
desk will clearly have to be larger than at present to accommodate it. 
Executives, who revel in the extra status that their necessarily larger 
offices and larger desks will confer, will pay recompense in the shape 
(and noise) of the air conditioning equipment that will also inhabit their 
offices. 
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CUCS — The Club and its members 

Right, here goes to see if I can stir up a bit of controversy and discussion 
in the ranks of the CUCS members without actually offending anyone too 
much. 

This is a short piece to be read in conjunction with Paul's questionnaire 
intro. The question is — what sort of a club is CUCS? 

• a forum for technical discussion 

• a job/swap-shop service 

• a lively social group 

• something no-one would be seen dead in 

• none of these 

• all of these? 

The answer that I would like to give is that is a healthy combination of 
the first three on the list, but it simply isn't true. It's mostly 1,2 & 4. 

CUCS has very few social events and those it does have tend to be 
desperately nargy. The party people (who also have some computing 
interests else they wouldn't be members) are kept away by the image 
CUCS has built up for itself of a cosy group of unsocial Anoraks. 

The Ed, myself and several others who are in CUCS aren't happy with 
the status quo and would like to see something done. What does 
everyone else think. Tell us, tell the committee. If you want to see CUCS 
become more fun and more welcoming, not just useful and "mildly 
interesting so long as I don't have to talk to any of those weirdos" then 
let's have your ideas. If you like it the way it is then say that as well, 
otherwise busybodies like me might come along and spoil it. 

Now I'm exaggerating a little here to make the point, but it's hard to 
stir most of you lot from terminal apathy and this might just do it. So fill 
in your questionnaires, mail me, mail Paul, whinge on Groggs, or 
Zinque. Just do something. OK? 

luv Wookus (JDW13) 
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Well after that outburst, here it is... 

CUCS QUESTIONNAIRE 

Our society is quite a large one with 114 members at the last count 
Some of its members past and present are big names in computing, and 
as such we are recognised and well supported by many computing firms 
locally and nationally. However, over the years the number of members 
actually turning up to meetings has dwindled. We hope to reverse this 
trend and get the society swinging again, but for this we need your help. 

Please fill in this questionnaire and return it to: Paul Theobald, Churchill 
College, or you can find a printable copy of it in the file 
CUCS.DATABUS.MAR89:QUEST on Phoenix which you can complete and 
mail to my ID, PMT10. 

Name . College . 

Course . Year . 

Do you own your own computers) ? 

If so, what ? 

Is it here at University with you? 

Which other machines do you regularly use? 


How would you regard yourself in computing: 

beginner, medium, experienced, very experienced? 

Are you more into hardware, software or both equally? 


Do you work for / have you ever worked for a computing/electronics 
firm, or had an article published in a magazine or similar? 

If so give details. 
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Which machines are you interested in? (please tick) 

□ Acorn □ Amstrad □ Atari □ P C 

□ Sinclair □ Phoenix □ Unix □ Workstations 

□ Transputers □ Supercomputers 

□ Others (please name) 

What are your interests? (please tick) 

O Graphics □ Games □ Music □ Maths 

O Number Crunching O Parallel processing 

O Real-time O AI □ Statistics 

O Others (please name) 

The society: 

Are you a regular attender of meetings? 

Do you think the subscription fee is too much, too little, or ok? 

Should there be more or less speaker meetings? 

Any ideas for speakers? 

Should there be more social events (eg. pub meets) ? 

Any ideas for some? 

What form of transport do you have (car, bike, foot etc) ? 

(So we could possibly organise some visits.) 

What else would you like the society to do? 

Why did you join the society? 

Does it live up to your expectations? 

For you, what is the best bit of the society (if any) ? 

(Speakers, discounts etc.) 

Any other comments: 
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Public Key Cryptography 

By Martin W Baxter, Pembroke 

Codes and ciphers involve a one-to-one relationship between one set 
of words, phrases, characters or symbols and another set of words or 
symbols. Traditionally a code would relate words or phrases with other 
words, for example relating the phrases "MR SMITH HAS ARRIVED" and 
"THE DOG HAS BARKED"; whereas a cipher might relate the character 
strings "HELLO" with "IFMMP", and "HAL" with "IBM". In both cases 
there is a rule, or set of rules, such as a code-book with relations like 
"MR SMITH = DOG"; or the rule: replace each letter with its alphabetical 
successor. 

Coding is performed by considering each word, phrase, character, or 
group of characters, and then deriving its relation in the other set 
according to the rules of the code. In both the above examples we could 
easily devise rules to give the original from the relation — that is to 
decode. We could re-sort the code-book entries according to the 
alphabetical order of the right hand side, and then look up "DOG" under 
D and see it was the relation of "MR SMITH". In the other case we 
would use the rule: replace each letter with its alphabetical predecessor. 
So given the code-book or rules for coding we can in both cases 
construct rules for decoding. 

Public Key Cryptography constructs a one-to-one relation between sets 
of numbers (which could represent ASCII strings) such that coding is 
performed by a relatively simple arithmetical rule, but constructing the 
decoding rule from the coding rule is nearly impossible. This has the 
advantage that there is no necessity to try to keep your method of 
coding secret (in jargon: the key is public), so that anyone and everyone 
can be told the encoding rules yet coded messages are still secure. 

This type of code was first considered by Diffie and Heilman in 1975, and 
the method used here was put forward by Rivest, Shamir and Adleman 
of MIT and is known after them as the RSA system. As it is based on an 
'NP' number theory problem, we must first digress into: 
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Mathematical Number Theory 

Notation: a = b (mod m) “a is congruent to b modulo m" 

that is a and b have the same 
remainder on division by m, or that m 
divides the difference between a and b 


a mod m 


a 


b 


the remainder obtained on dividing a 
by m 

a to the power of b 


gcd (a,b) greatest common divisor of a and b, 

the largest number dividing both a 
and b 


lc m[a,b] least common multiple of a and b, the 

smallest number which both a and b 
divide. In fact ab = gcd(a,fr).lcm[fl,fr] 


The two main number theoretical results that are used are: 


(1) EUCLID'S ALGORITHM 

Which proves the existence of and calculates integers x,y for each pair 
of integers a,b such that 


xa + yb = gcd(fl,b) 

(2) FERMAT'S THEOREM 

If p is a prime number and p does not divide a , that is gcd(p,a)=l, then 

A (p_1) = 1 (mod p) 

Note that this is not Fermat's Last Theorem which is as yet improved, 
but an earlier result known to be true. 
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Pick two primes p/q, and by Fermat (2) we have 

A (p_1) = 1 (mod v ) and a^ A) = 1 (mod q), 
for any suitable a (less than pq), and hence deduce 

flicmt P-W ] s 1 (mod pq) 

Setting L to be equal to lcmfp-l^-l], then we have 

If st = 1 (mod L) then a st = a (mod pq) and (a st mod pq) = a, (*) 
for any integers s,t. The cornerstone result now follows 


(( a s mod pq)* mod pq) = a 

Thus given s and pq we can associate with any a the number (a s mod pq), 
and this number can be re-associated with a by raising it to the t modulo 
pq. We thus have a system whereby we encode with s and pq, and 
decode using t and pq. It only remains to show that t cannot be 
practically calculated from s and pq and we have constructed a public 
key cipher. 

This can be seen in that t was effectively defined by s and L in (*), and 
calculating L from pq is equivalent to calculating p and q themselves — 
that is factorising the product pq. Supercomputer technology develops 
and papers point out various short cuts, but a length for p,q of 300 bits 
ought to be fairly safe in making the necessary code-breaking 
computation infeasible. 
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Practical Computing 

Assuming we work with primes p$ of about 300 bits each, we have to be 
able to: 

(i) generate primes of that size quickly 

(ii) perform arithmetical operations: + - x + mod on 600 bit numbers 

(iii) implement Euclid's algorithm 

(iv) perform the calculation a b mod m with 600 bit numbers 

Clearly the machine's own arithmetical routines will not cope quickly 
without support, and machine code programming could be useful. The 
bright spot is that all the numbers concerned are integers. 

(i) Checking by trial divisions that a number is prime takes as long as 
factorisation, and we have placed ourselves beyond factorisation limits. 
So we cheat and use the converse of Fermat's Theorem which says 

If = 1 (mod p) then p is prime 

This is not strictly true but it does not "miss" any primes and only claims 
primality for a few "pseudo-prime" composites such as 1729. In practice 
we run the test for a = 2,3,5,7 say, and we have a number of very good 
prime quality (over 99%). There are more sophisticated techniques based 
on similar principles. (See references) 

(ii) This is left for the reader, his machine and its libraries. Addition 
should be signed, and division may be integral. 

(iii) Euclid's Algorithm 

To return gcd (a,b) and x only of x,y in (1) above. In PASCALesque 

function gcd <a,b : integer) : integer ; 
var 

c f d,v,w,x : integer ; 
begin w:=0 ; x:=l ; 
repeat 

c:=(a mod b) ; d:=(a div b) ; 
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a:=b ; b:=c ; v:=x ; x:=w ; 
w:=(v - d*w) ; 
until (b=0) ; 
gcd:=a ; 
end; 

Though all arithmetical operations must be performed by the large 
number routines from (ii) and x should be preserved on exit. This is the 
fastest number theory algorithm known to man. 

(iv) Initially a 600 bit number to the power of another 600 bit number 
seems rather vast (10 185 bits), but with tricks we can do it in exactly 601 
bits using the operations in (ii). 

Let b(i) represent the value of the i bit of variable b and similarly for 
d(i) in the following routines. 

function product (c,d,m : integer) : integer ; 
var 

e,f,j : integer ; 
begin 

e:=0 ; f:=c ; 
for j:=0 to 600 

if (d(j) = 1) then e:=((e+f) mod m) ; 
f:=((f+f) mod m) ; 
next j ; 
end; 

function power (a,b,m : integer) : integer ; 
var 

c,d,i : integer ; 
begin 

c:=l ; d:=a ; 
for i:=0 to 600 

if (b(i) =1) then c:=product(c,d,m) ; 
d:=product(d,d,m) ; 
next i ; 
end; 

The largest number considered is 2m. The 600 in the FOR loops is the 
number of bits to which the arithmetic routines work. The former 
routine calculates ( cd mod m) using only addition, and the latter 
calculates ( a b mod m) using only the former. This is not the fastest 
algorithm known to man, but pretty speedy nonetheless. Both it and 
Eider run at speeds proportional to the log of the numbers involved. 
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What to do 

To set up and operate the system once the above has been programmed. 

(1) Find a pair of primes p,q by starting searching at a user given value 
using the primality test (i) or some other. 

(2) Calculate L = \cm[p,q] by dividing pq by gcd(p,q) found using Euler 
(iii). If you don't like division you don't have to. 

(3) Get a value of s from the user, checking that gcd(s,L) = 1, and getting 
x,y from Euler (iii). As xs + yL = 1, then xs mod L = 1, so fis equal to x. 

(4) Distribute s and pq to friends and enemies alike. 

(5) Code messages by sending any datum a (less than pq) to: a s mod pq, 
using (iv). 

(6) Decode messages by sending coded datum b to: b l mod pq, using (iv) 
again. 

(7) Take a well earned rest with a cup of something. 
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Software Protection — 
(Cr/H)acking for Fun 

Disclaimer: Whilst removing the protection from commercially 
available programs is intellectually rewarding, it is 
ethically unsound to then distribute the results to all and 
sundry, and I wish to unequivocally (and hypocritically) 
distance myself from such heinous, despicable and public 
spirited actions. (The Author) 

Now I've got the boring bit over, we can get down to the real stuff. 

Confessions of a ... 

I feel I ought to say (despite my ego) that I am by no means an expert on 
the subject described in this extremely well written and witty article, 
having started less than a year ago, and used only an Atari ST (for 
hacking — I have previously used a ZX81, Spectrum and 
Commodore 64). As a result the discussion will have to be about disc 
software for this and similar machines, although some of the principles 
are probably quite general (Vague or what?). 

What is Protection? 

This is probably a redundant section since most people reading this will 
be familiar with commercial software and the desire to avoid paying for 
it. You will also no doubt have found that, as a rule, simply trying to use 
the machines built in backup routines, or typing LOAD "name" followed 
by SAVE "name", doesn't get you very far (although there are, no doubt, 
some exceptions). This is because software houses don't like people 
getting hold of their software without paying for it (stingy lot). This 
unreasonable attitude has led to the development of various methods of 
varying deviousness to prevent people from copying said programs. 
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The Bad Old Days 

(The Land that Time (Nearly) Forgot) 

In the early days of tape based software, the simplest method was to 
make the programs run once loaded. Unfortunately there was usually a 
way to stop this, allowing the user to SAVE it as usual. Also common 
was not declaring explicitly to where a chunk of machine code was to be 
loaded. Of course, short programs were soon published in magazines to 
find out such things, and copying programs began to appear. The 
response of many companies was to write their own loading routines. I 
think this first appeared on the Commodore 64, where classics such as 
'Revenge of the Mutant Camels' and 'China Miner' took between 15 
and 20 minutes to load (no exaggeration). These new loaders were 
much quicker, and also allowed exciting things like music while the 
program loaded (probably not on the Spectrum). 

The problem with all of these methods is that, using an incredibly 
sophisticated piece of modern technology, ie. a twin tape deck, all but 
the most fussy of programs could be copied, and those that couldn't 
probably didn't load all that reliably in the first place. 

Back to Reality 

Okay, that's enough ancient history. Most software now is available on 
discs (if not to all users). Discs have the disadvantage (to the software 
houses) that the basic format of data on the discs is fixed by the disc 
controller used in the drive or computer — obviously the drive has to be 
able to read the stuff. This places certain restrictions on the methods of 
protection used, and also suggests (incorrectly) that anything you can 
read from a disc you can also write to it (more of this later). However, a 
lot of the people who play games on their computers don't understand 
how the machine works — they don't need to. As a result, many 
protection methods just rely on having things on the disc that a simple 
copier either refuses to try to copy, or can't make a very good job of 
copying. I think now is the time to become a bit more specific. 
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Disc Formats 

This is the name commonly given to any damaged disc that is left lying 
around on the floor (disc for mats — geddit?) [apauling pun — Ed]. No, 
seriously folks, disc formats are what take up half the space on a disc. 
So when a manufacturer says 1MB (Megabyte — one million 
characters) unformatted capacity it means the disc drive probably has 
an 900k+ unformatted capacity, and you might be able to use about 
700-800k of it if you're lucky. This is because the disc is divided up into 
tracks (concentric rings) and sectors (parts of these tracks), although the 
surface of the disc is all the same. A track is accessed (controversial use 
of a noun as a verb) by moving the disc head (the bit that reads stuff off 
the disc) towards or away from the centre of the disc. Most disc drives 
allow about 80 tracks. 

To tell the drive where to find the start of each track, there is a hole near 
the centre of the disc (not the big one, dummy). This is called an index 
hole, and when the hole passes between a light source and detector a 
pulse is sent to the disc controller. This pulse is called (... wait for it...) 
an index pulse. So, when the disc controller receives an index pulse it 
knows that the head is at the start of a track. It can then read in all the 
data in the track, right? Sorry, it's not that simple. 

The disc is revolving quite quickly, and it would require great accuracy 
to be able to start reading exactly at the start of the data, neither too 
early nor too late, so each track has lots of empty space and pointers 
saying things like '3 Miles to Sector 1' and 'Just around the next comer' — 
really. This is the disc format. The following information is about the 
WD 1772 disc controller, but it should apply equally to the 1770, and 
should be similar for most other controllers (Aside - Does anyone know 
the controller used by the AMIGA? Please contact GJS12 about it , and he 
will tell me). 

The track format looks like this : 

— A-D-A-D-A-D-A-D- ... - A-D— 

where — is a big gap, - is a little gap, A is an address marker and D is a 
block of sector data. All of these things are put onto a track by giving the 
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disc controller a command which says do a format, and then giving it a 
list of all the information to go into a track. 

An address marker is a little block of data (about 9 or 10 bytes — I can't 
be bothered to look it up) that contains information about which track 
you are on (in case you get lost), which sector is coming next, how long 
it is, and a checksum to make sure the address marker hasn't become 
corrupted. The data block has a byte to say that it really is a data block, 
and the group of bytes that make up the sector, and finally a checksum 
on the data itself. 

So You Thought That Was Hard 

So far I have avoided the issue of how the drive knows where the 
address markers and data blocks start. If you want to remain blissfully 
ignorant just skip this bit. The data is stored on this disc by modulating a 
sine wave, because you cannot write data onto magnetic media below a 
certain frequency. This modulated waveform also carries a series of 
regular clock pulses. [This is a greatly simplified explanation — Ed] 
When a particular series of bytes is included in a format ($F5,$F5,$F5), the 
controller interprets this and writes a different group of bytes onto the 
disc ($C1,$A1,$A1 or something like that), but without the clock pulses 
underneath. These groups of bytes are called sync blocks, and they also 
reset the internal checksum counter. If you're really on the ball, or have 
read about this elsewhere, you might have realised that there are 
certain things you cannot write to the disc during a format, such as 
$F5,$F5,$F5, because the controller converts them. Most bytes above $F0 
are altered in some way, but only whilst formatting. However, bytes 
written to a sector are not changed. This is important. 

Okay, you can come out from behind the settee now, the grisly bits are 
over (at least for the moment). The disc controller is quite capable of 
calling tracks anything you want it to (but nothing much above $F0), and 
the same goes for sector numbers. The length of sectors can also be 
altered. I ought to mention the commands offered by the disc controller. 
These are things like Read Track (everything, including gaps and sync 
bytes etc.). Write Track (=Format), Read Address (the next address 
marker on the track). Read Sector (you give it the number). Write 
Sector, Seek Track, Step In (next track). Step Out (previous track) and 
Restore (find track 0). 
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Disc Protection (at last) 

The simplest way to protect a disc is to miss out a whole track or sector, 
so that simple disc backup programs can't find it and give up. This is 
usually checked by the program, so that if the sector is there, it crashes. 
A similar technique is to put an odd numbered, or different sized, sector 
in the middle of a track. These tracks can all be duplicated, as long as the 
sectors don't have numbers above $F0 (perhaps some controllers could 
do this). A more subtle approach is to put all the sectors in, but make it so 
that half of one or two sectors are badly written so that random 
garbage appears there when they are read, but the first half of the 
sector is all right. This is very difficult to copy. I have also found discs 
with special bits of data inserted into the gaps between sectors, and 
even one disc with no sectors at all (apart from the boot sector and 
loader — stay tuned) — all of the data was put on the disc with a write 
track (Backlash, if you're interested). I thought I had done well to copy 
this, until I found a commercially available copier which handled it — 
this impressed the hell out of me. 

DIY 

Given that there exist discs such that they cannot be exactly replicated 
on a home computer (sounds like a mathgmatical proof), another 
method must be found in order to copy the software. This is hacking, or 
cracking. The idea is to modify the program on the disc so it couldn't 
give a damn if track 79, sector 1 is there or not. This can be surprisingly 
easy. The tools I use are: an Atari ST (substitute your own machine 
here), printer (essential, really!) MON-ST (monitor/debugger), 
ST-Doctor (simple memory & disc editor) and a handful of home 
grown disc utilities. The most useful of these are ones that can display 
the contents of a whole track, list out address markers, and copy fairly 
normal discs, ignoring any oddities. 

I start by reading all the address markers on the disc — this tells me 
what sectors are probably present (you could have an address marker 
without a data block), how long they are, and how the tracks and 
sectors are numbered. I then examine the boot sector. This is the very 
first sector on the disc, and if it contains a certain pattern of bytes the 
computer will load this as soon as you switch on and put the disc in. This 
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is normally used to hold a small loader routine, which then can load a 
larger loader from another part of the disc. Another way to make 
loaders run automatically is to put them in an AUTO folder (ATARI 
jargon for a directory called AUTO). Certain programs put in here will 
auto-run. Either way you have to load these programs into the monitor, 
where you can then disassemble them (Did I mention a need to 
understand machine code? — Sorry!). The first thing to look for are calls 
to the operating system. These are handled by TRAPS on the ST. 
MON-ST allows you to search for any instruction whose mnemonic 
contains a particular string, eg. TRAP. This facility is also good for 
finding relative jumps to a location. These calls are used to get 
information off the disc in the usual way, either as named programs or 
as individual sectors. This is sometimes the only sort of disc access in a 
program. If this is the case you are in luck. The alternative is to program 
the disc controller directly. 

To find out if this is done, I search through the program looking for 
references to the addresses at which the controller's registers appear in 
the memory map ($FF8604 and $FF8606 on the ST). I have found standard 
blocks of code which are, by and large, the same whoever the program 
is by. These do things like send a command to the disc controller, read a 
sector, and wait till it has finished doing something, giving an error if it 
takes to long. Once you have found the sections with any sort of disc 
access in, print them out, switch off and go away and suss out what it's 
doing. I've found that the best way for me. Once you have these sorted 
out, hunt through the program until you find calls to these routines, and 
eventually you should find a bit of code that goes into an infinite loop if 
the carry flag is set, or if some bytes don't match some other bytes, or 
the program will terminate cleanly or print a message. All of these 
things are possible, and it shows that at that point in the program a test 
has been made of the contents of the disc. The easiest way to get round 
this is to remove the offending branch instruction, or make it into a 
'branch always', or something like that. Make a list of the alterations 
you make to the memory, then later you can use a disc editor to change 
the disc (a copy made with a simple copier, not the original), and with a 
bit of luck it will run. If it doesn't you either made a mistake in altering 
the disc or you missed a test in the program. The way it fails to work 
should give you a clue. 
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That all sounded very easy, but what if you can't make a simple copy of 
the disc? This happens if the sectors and tracks have been numbered in 
some perverse way. In these cases it is best to modify the loader, or 
write another version of the loader, so that it can read in the data, and 
then save it onto a normal disc — this is normally very easy. Sometimes 
this is the only form of protection, so once you have modified the loader 
on the copy to look for sectors with normal numbers the program may 
work, eg. Virus - total time required = 3 hours including lunch. 

The Nasties 

Up to now, hacking has been a piece of cake (profound, huh?). Some of 
the more devious programs have large sections of encrypted code which 
need unscrambling before they can be run. You have to take these as you 
find them, but watch out for programs which calculate a checksum on 
themselves to do the unscrambling. Any changes you make will ruin this. 
Possible solutions — work out the checksum once and make sure the 
program always uses that, or unscramble the whole thing permanently. 

One particularly nasty example of encryption is Captain Blood, which 
performs its decryption using all the available registers, including the 
stack register, and then calls subroutines, putting new values in the 
bottom area of memory which normally holds the interrupt vectors, but 
now has to hold part of the loader. As a result, MON-ST just gives up 
because once the Supervisor stack has been mucked about with, it 
doesn't know whether it's coming or going. One of these days I'll crack 
it (probably). I also hate Starglider II (the loader), because it's got so 
much junk in to handle the AMIGA disc controller as well, and the whole 
thing takes up so much memory there isn't room for it and the monitor. 
Anyone would think they didn't want it to be copied. [Erm , yes — Ed] 

Just before I finish, a mention for a clever loader — Super Hang On. 
This is the only ST loader I have seen so far which uses interrupts, 
allowing sampled sound to be played while everything is being loaded 
off the disc. It makes understanding what is going on ten times harder 
because you find that there aren't any calls to some of the loading 
routines, it's just that the interrupt vectors have been changed to point 
to them. 
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And Now, The End is Near, It's Time To Face The 
Final Curtain... 

Sorry, got carried away there. Anyway, that's about it. I'm sure I 
haven't covered everything, but I have spent four hours on this thing 
(including lunch) and it was at short notice. Now, I want to see how the 
spelling checker copes with Starglider II. 

Bye. 

May the cube be with you! + 
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New Languages Compete With APL 

A Usually Reliable Source 
Somewhere in New England 

APL, BASIC, FORTRAN, COBOL... these programming languages are well 
known and (more or less) well loved throughout the computer industry. 
There are numerous other languages, however, that are less well 
known yet still have ardent devotees. In fact, these little-known 
languages generally have the most fanatic admirers. For those who 
wish to know more about these obscure languages — and why they are 
obscure — I present the following catalogue. 

SIMPLE 

SIMPLE is an acronym for Sheer Idiot's Monopurpose Programming 
Linguistic Environment. This language, developed at Hanover College 
for Technological Misfits, was designed to make it impossible to write 
code with errors in it. The statements are, therefore, confined to BEGIN, 
END, and STOP. No matter how you arrange the statements, you can't 
make a syntax error. 

Programs written in SIMPLE do nothing useful. They thus achieve the 
results of programs written in other languages without the tedious, 
frustrating process of testing and debugging. 

SLOBOL 

SLOBOL is best known for the speed, or lack of it, of its compiler. 
Although many compilers allow you to take a coffee break while they 
compile, SLOBOL compilers allow you to travel to Bolivia to pick up the 
coffee. Forty-three programmers are known to have died of boredom 
sitting at their terminals while waiting for a SLOBOL program to 
compile. 
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VALGOL 

From its modest beginnings in Southern California's San Fernando 
Valley, VALGOL is enjoying a dramatic surge of popularity across the 
industry. 

VALGOL commands include REALLY, LIKE, WELL, and, Y*KNOW. 
Variables are assigned with the =LIKE and =TOTALLY operators. Other 
operators include the California Booleans, FERSURE and NOWAY. 
Repetitions of code are handled in FOR ... SURE loops. Here is a sample 
VALGOL program: 

LIKE Y*KNOW (I MEAN) START 
IF PIZZA =LIKE BITCHEN AND 
B =LIKE TUBULAR AND 
C =LIKE GRODY**MAX 

THEN 

FOR I =LIKE 1 TO OH MAYBE 100 
DO WAH - (DITTY**2) 

BARF(ME) =TOTALLY GROSS(OUT) 

SURE 

LIKE BAG THIS PROBLEM 
REALLY 

LIKE TOTALLY(Y*KNOW) 

VALGOL is characterized by its unfriendly error messages. For example, 
when the user makes a syntax error, the interpreter displays the 
message: 

GAG ME WITH A SPOON! 

LAIDBACK 

Historically, VALGOL is a derivative of LAIDBACK, which was developed 
at the (now defunct) Marin County Center for T'ai Chi, Mellowness, 
and Computer Programming, as an alternative to the intense 
atmosphere in nearby Silicon Valley. 

The centre was ideal for programmers who liked to soak in hot tubs 
while they worked. Unfortunately, few programmers could survive 
there for long, since the centre outlawed pizza and RC Cola in favour of 
bean curd and Perrier. 
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Many mourn the demise of LAIDBACK because of its reputation as a 
gentle and non-threatening language. For instance, LAIDBACK 
responded to syntax errors with the message: 

SORRY MAN, I CAN'T DEAL WITH THAT. 

SARTRE 

Named after the late existential philosopher, SARTRE is an extremely 
unstructured language. Statements in SARTRE have no purpose; they 
just are. Thus SARTRE programs are left to define their own functions. 
SARTRE programmers tend to be boring and depressed and are no fun at 
parties. The SARTRE language has two basic data types, the EN-SOI and 
the POUR-SOI. The EN-SOI is a completely filled heap, whereas the 
POUR-SOI is a dynamic structure which never has the same value. The 
structures are accessed through the only operation defined in SARTRE, 
nihilation, which usually results in a ?BAD FAITH at PC 02AC040 error. 
Comparisons in SARTRE have a peculiar form in that the IF statement 
can take no arguments and simply reads 

IF; 

Similarly, assignments can only be of the form 

WHAT-IS := (NOT WHAT-IS); 

since in SARTRE the POUR-SOI is only, and exactly, what it is not. 
Although this sounds confusing, a background process, the NIHILATOR, 
is constantly running, making any such statements (or any statements at 
all, for that matter) completely meaningless. 

Programs in SARTRE do not terminate, of course, since there is No Exit. 

FIFTH 

FIFTH is a precision mathematical language in which the data types 
refer to quantity. The data types range from CC, OUNCE, SHOT, and 
JIGGER to FIFTH (hence the name of the language), LITER, MAGNUM, and 
BLOTTO. Commands refer to ingredients such as CHABLIS, 
CHARDONNAY, CABERNET, GIN, VERMOUTH, VODKA, SCOTCH, 
BOURBON, CANADIAN, and WHATEVERSAROUND. 
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The many versions of the FIFTH language reflect the sophistication and 
financial status of its users. Commands in the ELITE dialect include 
VSOP, LAFITE, and WAITER' S (RE C OMMENDATION ). The GUTTER dialect, 
instead, has commands for THUNDERBIRD, RIPPLE and HOUSE(RED). The 
GUTTER dialect is a particular favourite of frustrated FORTH 
programmers who end up using this language. 

c- 

This language was named for the grade received by its creator when he 
submitted it as a project in a graduate programming class. C- is best 
described as a "low-level" programming language. C- combines some 
of the power of machine language with all the flexibility of machine 
language. In general, the language requires more C- statements than 
machine-code instructions to execute a given task. In this respect, it is 
very similar to COBOL. 

LITHP 

This otherwise unremarkable language is distinguished by the absence 
of an "S" in its character set. Programmers must substitute "TH". LITHP 
is said to be useful in prothething lithtth. 

DOGO 

Developed at the Massachusetts Institute of Obedience Training, DOGO 
heralds a new era of computer-literate pets. DOGO commands include 
SIT, STAY, HEEL, and ROLL OVER. An innovative feature of DOGO is 
"puppy graphics", a small cocker spaniel that occasionally leaves 
deposits as he travels across the screen. 
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Wild and Wacky C Programs 

Here are some winners from the "International Obfuscated C Code 
Contest". They are written for the Unix 'CC' compiler, pushing it to its 
limits and need adjustment to work on the Phoenix ANSI C compiler. 
You can find all these and more in PMT10.SILLY:C. 


This first example is "the strangest appearing program" — it resembles 
modem line noise. It scrolls the input text across the screen. 

♦define o define 

#o _o write 

#o ooo (unsigned) 

#° o_o_ 1 

#o _o_ char 
#o _oo goto 
#o _oo_ read 
#o o_o for 
♦o o_ main 

#o o_ if 

#o oo 0 

#o _ol_, ,_) (void)_o(_,_,ooo(_)) 

#o o (cTjd_« ((o_o_« (o_o «o o_)) + (o_o_«o_o_))) + (o_o_« (o_o_« (o_o_«o_o_))) 
o OT o =oo , r , r oF; oo ; : = o-o o ; : 

_o (o o , , -o o~^ T~-o o : ));o o(; ;~oTo o , ,r W",o_o_) , ; 

_o(o_o_, ,r 7o o_);o (— )_oo _;_o (o_o_, "\n",o_o_);_:o ( ° oo ( 

oo_,_,_o) r_oo _;7 


The following program won the award for best layout. It produces 
something to do with the shape of the program. 


argv, 

r 

♦define 
x ;if 
S P(j 


argc ) 


int i, 

(P( ! 

) >2 ? 

for 

_exit(argv[argc- 2 
P ( a ) char 

/* - by E 


;main( 
int argc 
char *argv[];{int 
j,cc[4];printf(” 
i ) 

. j : 

(i= 0; 

/ cc[l*argc) |-1«4 


{ 

ricM 


a ; 
arsh 


while( 


extern int 
errno 
; char 
grrr 
r, 

p (); 

choo choo\n" ) ; 

I cc[ ! j ] 

i ){* argv[i++ +!-i] 
i++ ); 

) ;print fr%d M ,P(’•"));}} 


a > 
all- 


'/) 


B 


} 
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This one was voted the "worst abuse of the C preprocessor", looks like 
Morse Code and does in fact generate Morse code. 

tdefine DIT ( 
tdefine DAH } 
tdefine DAH ++ 
tdefine ETTDAH * 
tdefine DAHDIT for 
tdefine DIT_DAH malloc 
tdefine DAH DIT gets 
tdefine DAHDIT char 

DAHDIT “DAH []="ETIANMSURWDKGOHVFaLaPJBXCYZQb54a3d2f16g7c8a901?e’b.s; i, d:" 

“main FIT “ DAH{ DAHDIT 

DITDAH DIT,DITDAH DAH ,DITDAH DIT , 

DITDAH “DIT ,DITDAH DIT DAH DIT “ 

DAH,DITDAff DAH DIT DIT DAH;DAHDIT 
DIT DIT=DIT DAH DIT 81 DAH,DIT = DIT 

DAH; DIT==ETAH DIT DIT DIT DAH“ “DIT 
UTT , \n T DAH DAH “DAHDIT DTT DAH - 15TT; DITDAH 
DAH ; DIT DIT DITDAH 

DIT 7“DAH DIT DITDAH DIT DAH: ' ? 'DAH, DIT 
DlT'“'FAH,DAH DAH DAH DAHDIT DIT 
DITDAH DIT =2“DIT ■= DAH ; DITDAH DIT &&DIT 
DITDAH DIT T=DIT DITDAH DAH >=' 3 ’? DITDAH 
DAH &22J: DITDAH DAH DAH DAff; DIT 
DITDAH DIT DAH DAH, DIT DAH DAH 

DITDAH DIT += DITUlTDAH DTT~5='a*? DITDAH _DIT -'a':0 

DAH;} DAH DlT DIT DAH{ “ DlT DIT 

DIT >7? DAH DIT “ DIT »T"DAH: • \0 * DAH; return 

DIT“&17" 1 "— *:*-*;} DIT DlT DIT DAH DAHDIT 

DIT~; {DIT void DAH write DIT T,&DIT“,1 DAH;} 


This was the "most adaptable program", and compiles three ways. 

cat =13 /*/ >/dev/null 2>&1; echo "Hello, world!"; exit 

* 

* This program works under cc, f77, and /bin/sh. 

★ 

*/; main() { 
write( 

cat-cat 

/*, ’ ( 

*/ 

,"Hello, world!" 

cat); putchar (-cat); } /* 

,) •) 

end 
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And finally this one "performs something non-simple in a complex 
way". It calculates e, the base of natural logarithms, to an infinite 
number of places — well at least until you run out of filespace! 

typedef struct n{int a:3, 
b:29;struct n*c;}t;t* 
f () ;r () {}m(u) t*u; {t*w, *z; 
z=u->c,q(z) ,u->b=z->b*10, 
w=u->c=f(),w->a=l,w->c=z-> 
c;}t*k;g(u)t*u;{t*z,*v,*p, 

*x;z=u->c,q(z),u->b=z->b,v 
=z->c,z->a=2,x=z->c=f (), x 
->a=3,x->b=2,p=x->c=f(),p 
->c=f (),p->c->a=l,p->c->c= 
v;}int i;h(u)t*u;{t*z,*v,* 
w;int c,e;z=u->c,v=z->c,q{ 

v) ,c=u->b,e=v->b,u->b=z->b 
,z->a=3,z->b=c+l,e+9>=c&&( 
q(z),e=z->b,u->b+=e/c,w=f( 

),w->b=e%c,w->c=z->c,u->c= 

w) ;}int<*y[43) 0={r,m,g,h}; 
char *sbrk();main(){t*e,*p,*o; 
o—f(),o->c=o,o->b=l,e=f(), 
e~>a=2,p=e->c=f(),p->b=2, 
p->c=o,q(e),e=e->c,(void)write 
(1,”2.2);for(;;e=e->c)(q(e), 
e->b=write(l,&e->b[”0123456789”3, 

1);} }t*f () {return i | | (i=1000, 

k=(t*)sbrk(i*sizeof (t))),k+—i; 

}q(p)t*p;{(*y[p->a3)(p);} 


54 



DATABUS March 1989 


THE YUPPY 

Review by Paul Theobald 

Here is a review of the latest offering from Anorax, the small hi-tech 
Cambridge firm striving to follow in the footsteps of their local rivals 
Acorn and Sinclair, and make a big impact in the microcomputer 
industry. Their new machine is aimed at the high end of the market and 
is obviously aimed at the social group of the eighties, affectionately 
known as the yuppies. 

On taking the machine out of its box, you find... another box. A sleek, 
black, rectangular box about three inches thick like a briefcase. In fact, 
with the carrying handle pulled out of its recess it looks exactly like a 
briefcase. At the top, each side of the handle is a combination lock. On 
turning to the correct combination, the lid can be lifted to reveal 
underneath a full QWERTY keyboard, and the underside of the lid is a 
plasma screen. The review model was jet black all over with the 
exception of the lettering on the keys which was a slightly lighter shade 
of black, just visible to the naked eye in bright sunlight if you view them 
with a slight squint. The only other marking is a fine hologram of the 
company's logo, an anorak floating in 3D space, mounted at the bottom 
corner of the screen. The computer is totally portable with its own 
power supply and screen, yet sockets out the back allow it to be driven 
from the mains (which also recharges the battery), and the plasma 
screen can be removed entirely and replaced with a standard VDU 
connected into the RGB socket. The case is available in a wide variety of 
colours as well as gloss black. These include metallic silver; fluorescent 
red, yellow and blue for those trend setters amongst us; and the same in 
pastel shades. 

The plasma screen seems quite small on first appearance. However due 
to the ultra high resolution offered by this new technology the standard 
80x32 screen is easily readable and it will cope with the maximum size 
of 132x96 in the WIMP environment mode allowing lots of windows 
spread over the screen. This however is not the limit to the screen size. 
The screen can be expanded in physical size by the addition of 'snap on' 
screens to the initial one. Each of these extra screens is the same size as 
the original and simply plugs into the sides or top of this screen. Each 
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has its own inbuilt display memory which can be configured to lie at any 
address so that screens can for example each display different 
information, or can all display the same thing, giving the 'TV shop 
display' effect. Of course each of these screens can have further units 
plugged into them allowing an almost infinite screen size, though it is 
rather hard on the batteries! 

Next to the keyboard are three thin slots. These are for the Yuppy's 
version of discs, small credit card sized pieces of plastic coated on each 
side with a magnetic layer. In fact the reader can read standard credit 
cards as well, which is put to a good use as explained later. The 
principle behind these cards seem to be similar to standard floppy discs, 
except that instead of working on a 'polar' track and sector basis, they 
work in 'Cartesian' x and y coordinates. These are favoured to 
standard circular discs since the data will be stored with a uniform 
density, not more dense at the centre as for circular ones, and also the 
disc are easier to carry around, fitting into any credit card wallet. 

To start the machine, one of these cards must be placed in the upper slot. 
All users are issued individually with a card, which contains details 
about themselves such as name, address, password, and various startup 
options. These can then be customised by the user so that say 132 column 
mode output is chosen, or that condensed error messages are selected, 
or the startup tune changed etc. This card is placed in the top slot 
whereupon the computer automatically starts the login sequence and 
remains there for the rest of the session. On finishing a session the card 
is ejected, and the machine waits in 'stand by' mode for the next time. 
This card also allows a way of charging for computer use if there are 
likely to be several users of the machine. It can hold your current credit 
in CPU seconds, which is decremented as your session progresses. This 
credit can be recharged by the 'superuser' of the system at some later 
date for a fee, depending on the installation, say in an educational 
establishment it may be done for free at the beginning of each term. 
More often that not though, the machine will only have a single user, 
who is also the superuser, and no accounting need be done. 

The software that comes with the Yuppy is not so much bundled as 
wrapped in silver paper and tied with a ribbon. It is all on ROM, and 
fully integrated so that all applications can talk to one another. Each is 
controlled under a WIMP environment with windows popping up all 
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over the screen. These windows can be of any shape: square, circular, 
oval, or user defined, they can even have a hole in the middle so you can 
see what is going on in the window behind! As usual there is a 
wordprocessor and a spreadsheet. Also there is a comms package which 
allows you to send data anywhere over the phone network. The Yuppy 
is fitted with its own internal cell phone, so none of these unsightly 
acoustic couplers or modems are necessary. Within the comms package 
is software to buy/sell shares on the stock market, which also gives 
graphical results of how well your shares are doing, and an 'EFT' 
terminal, that's a cashpoint machine to us. This allows you to place your 
credit card, from any of the standard banks and building societies as 
well as Access and Visa, in one of the slots, and the bank will be dialled 
automatically. Assuming you type in the right PIN, from here you can 
examine your balance, pay for holidays etc. on Prestel. This even allows 
you to charge directly to your bank instead of using up credit units on 
your master card. This means that a software writer can claim royalties 
directly from a user as a program is run, or can charge for accessing 
various pieces of information in a similar way to Prestel at the moment. 

On looking round the back of the micro, there is the usual plethora of 
sockets of varying shapes and sizes. From left to right there is the 
external power socket, for when the batteries start wearing down, to 
plug directly into the mains; an RGB socket for connection to a full size 
colour monitor; two phono sockets for connection of stereo sound to 
your hi-fi, and a rather strange looking D-type jobby. On inspection in 
the user manual this is said to be a digital audio socket for connection to 
your CD or DAT player. Apparently Anorak are in the process of 
designing a real-time digital amplifier / graphic equaliser package 
which allow you to plug your CD player straight into the Yuppy and then 
to hi-fi / speakers with perfectly amplified sound. This opens up the 
exciting possibilities of producing your own digital music or recording 
your CDs onto the magnetic cards, from where you can digitally 
remaster them to produce weird and wonderful effects. Carrying on 
down the line is an RS423 socket for connection to the outside world the 
easy way rather than using the cell phone, and a socket for connection 
to a parallel printer. This is primarily meant for connection to Anorak's 
own printer, but with a little bodge can be made to support any 
standard parallel printer. 
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Anorak is currently producing a couple of peripherals for its new 
computer with the promise of more later as outside suppliers get in to 
the market. Currently you can buy Anorak's printer, a compact little box 
which connects neatly to the side of the Yuppy. It can take standard 
eleven inch fanfold paper, but also allows printing onto filofax sized 
pieces of card which you can slot into your filofax and carry around with 
you. Anorak are in the process of writing a printer driver for these 
pages, which will come with a program to print out the calendar for any 
year onto a page, and one to automatically generate an index to put at 
the back of your filofax, so at a glance you can tell where each important 
piece of information is kept. The other add-on is a remote control 
handset with all the main functions of the computer available at the 
touch of a button. This doubles up as a games joystick and a mouse so 
you can fight all those nasty aliens or design your new circuit board 
without getting out of your favourite comfy chair. 

Conclusion 

The Yuppy is a wonderful machine, with lots of new ideas built in. It is 
ideal for anyone of the new generation after which it is named, and will 
look great in the office of any top executive, or for that matter next to 
the four foot flashing light hi-fi stack in any student's room. At its price 
of around £1,500 it is a real bargain for those that can afford it. Its 
popularity will depend somewhat on the support from Anorak and 
other companies, as well as all those little computer whizz kid students 
writing zappy games for it, but if the rest of the hardware and software 
are as good as the initial package, then Anorak are on to a real killer. A 
'Pan-Galactic Gargle Blaster' of a computer! 
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CROSSWORD 

This week's crossword is by James O'Gunk 



ACROSS 

1 30 across plus first prime 

4 Couple in a prime sandwich end up 
as a Boeing 

7 Backwards space travelling with the 
Blue Danube without a score 

8 A gross mix up ends as a square 

10 Disciples turned round for a 
celebration 

11 Ton of 3 bullseyes 

12 4 x 15 across + 6 down 

13 People this age shouldn't see those 
sort of films 

15 See 27 down 

17 Tchaikovsky ends up with a few 
bangs. 

19 Baby according to 26 across 

21 A dozen reasons for Protestant 
march 

23 (16 down + 8x1 across) x 3 

26 Life begins at Castlemaine 

28 Ohio mentioned in Buchan's steps? 

29 Uncool vice ring still gets applause 
for it 

30 Nelson at Lords 

31 Lemon which has lost an era still 
not millenium 


DOWN 

1 Surely not the 100 years' war 

2 Digital triangular number 

3 Midnight ana a bit gives a quartic 

5 Pies losing pieces roughly put 
together by Magnificent 

6 Sum of 2 trinity palindromes 

8 Irrational and I flee vile end to a 
war 

9 Three prime factors in a deaning 
fluid 

11 Five bits fivefold 

12 I add to my CD to get a prime 

14 I get lost in the ultimate answer 

16 See 23 across 

18 See 27 down 

20 Henry I's age in binary when he 
married - lost 3 rings but gained 1 
ending up with the wedding year 

22 8 across times nought to the 
nought 

24 Red balloons almost a ton, 
according to Nina 

25 I get a couple of rings and a letter 
from the Queen on my birthday 

27 (+18d+15a) Bush rings up Swap 
Shop 

29 Live, that is, without 


59 




DATABUS March 1989 


Competition Time 

Well here it is, your chance to show off and show how clever you are! 
There may be a prize for the winner(s) if the entries are good enough 
and we have enough money left in the club coffers after producing this 
fun-packed, high quality magazine which is being given free to all you 
members. (Anyone reading this who isn't a member cough up now or 
we'll send in the heavy squad. Remember Big Brother is watching you!) 
The best entries will be published in the next issue of DATABUS 
whenever that'll be. In another four years time again probably! 

Anyway here is the competition. I'm sure some of you have seen in 
various publications IK Noughts and Crosses programs, or a one line 
Space Invader game, or even a complete Mandelbrot drawing program 
fit onto a Beeb function key, or even some of the strange C programs (if 
you can call them programs) given on page 52. Well I want you to do 
something similar. I want you to write a program as short as possible to 
do something equally clever or spectacular. The program can be written 
in any of the standard languages around on a Beeb or on Phoenix (eg. 
BASIC, Pascal, C or even a Phoenix command file) with the one 
restriction that the text file containing the source program be less than 
512 bytes long. Consideration will be taken of the size of the source code 
as well as that of the compiled object code and any variable storage 
necessary, and of the quality and sheer cleverness of the programming 
(please nothing too naughty like poking directly to discs or anything) 

Send your entry as a listing or by electronic mail to Paul Theobald 
(PMT10), Churchill College, stating your name, college, what 
machine/language it rims on as well as a brief description of what it 
does, how it does it (ie. the clever bits) and instructions. 
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The Cover Story 

For those of you who wonder how the cover of this magazine was 
produced, here follows the program, written in PostScript. 

%!PS-Adobe-l.0 
%%Title: Fractal Tree 
%%DocumentFonts: 

%%Creator: Paul Martin, PM111@UK.AC.CAM.PHX 
%%CreationDate: 11 March 1989 © Paul Martin 
%%For: PM111 
%%Pages: 1 

%%BoundingBox: 0 0 600 800 
%%EndComment s 

/edef {exch def} bind def 

/rnd {rand 10000 mod 10000 div} def 

/initturn 

{ num 2 mod 0 eq 

{ /rot num 2 div 1 sub ang mul ang 2 div add def 

} 

{ /rot num 1 sub 2 div ang mul def 

} 

ifelse 

/direction direction rot add def 

} def 

/branch % len ang num wid dwid branch 

{ 10 diet 

begin 

/dwid edef /wid edef /num edef 

/ang edef /len edef 

save 

len 2 gt 

{ currentpoint 

/curry edef /currx edef 

/currd direction def 

wid setlinewidth 

/rot rnd 0.5 sub currd mul def 

/direction direction rot sub def 

newpath 

currx curry moveto 
direction rotate 

rnd 6 mul 7 add 10 div len mul 0 rlineto 
direction neg rotate 
currentpoint 
stroke 
moveto 
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/len len 0.7 mul cvi def 

initturn 

num 

{ direction rotate 

len ang num wid dwid mul dwid branch 

direction neg rotate 

/direction direction ang sub def 

} 

repeat 

/direction currd def 
currx curry moveto 

} 

if 

restore 

end 

} def 
/tree 

{ /direction 0 def 
gsave 
.6 setgray 
300 134 moveto 
1 1.25 scale 
90 rotate 
branch 
grestore 

} def 

%%EndProlog 
%%Page: 1 1 

144 30 2 10 0.7 tree 
showpage 

%%Trailer 
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